home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1827 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 23 Jan 1996 22:23:57 +0100
  6. Organization: dis-
  7. Message-ID: <4e3jld$la@serpens.rhein.de>
  8. References: <4e0jhq$f0q@sunsystem5.informatik.tu-muenchen.de> <4e114i$4o8@serpens.rhein.de> <4e371l$92b@sunsystem5.informatik.tu-muenchen.de>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
  12.  
  13. >what am I ignoring ? I just can't ignore your sad 'c0d3r' talk.
  14.  
  15. sad it is..
  16.  
  17. >naaah. I try to get OSsy solutions, but if I loose too much vs
  18. >a "vanilla A1200 hack", then I at least will provide the hack
  19. >as option. What is bad about this.
  20.  
  21. that your solutions consist of hacks.
  22.  
  23. If you want hacks then shut down the system and reboot afterwards.
  24. And stand for it.
  25.  
  26. If you want the advantages of system-compliant code then use the
  27. OS and don't mix OS and hacks.
  28.  
  29. >yes, in can optimize that way, but this could still be less ideal
  30. >than direct render to vram.
  31.  
  32. Sure. In the same way that WaitTOF() could suddenly busy-wait, no ?
  33.  
  34. >??? the driver can give you fastmem, chipmem, vram, swapspace,
  35. >whatever depending to architecture...
  36.  
  37. And your code has to adapt to it. It even has to follow rules.
  38.  
  39. >|> But why should writing bytewise be faster ?
  40. >texture mapping loops write bytewise to fastmem. If vram is as fast,
  41. >you can render into it and save the time of copying.
  42.  
  43. How would you know ? For most systems the VRAM wouldn't be cachable.
  44. Each write access is passed to the RAM. So, writing bytes causes
  45. 4 accesses per word. Writing to (write-)cached FastRAM and copying
  46. later just causes 3 accesses per word.
  47.  
  48. >|> >So making the OS more sucking
  49. >|> Again just insults.
  50. >I explained what I mean. 
  51.  
  52. To make you more sucking ?
  53.  
  54. >On architectures where vram is quite quick and fastmem is quite slowe and
  55. >copying is done with cpu it does need that. This time you are the one that
  56. >doesn't take care of all possible architectures!
  57.  
  58. I don't have to, the driver does. But your code has to. It even has
  59. to take into account every possible combination of framebuffer, CPU,
  60. bus architecture, etc..
  61.  
  62. >you are talking about a game on wb window ? I hope also future Amigas
  63. >will provide 320 pix fullscreen. that's what games just need.
  64.  
  65. Some future Amigas will not provide 320 pix fullscreen.
  66.  
  67. Some graphics cards might provide a 320 pix fullscreen by zooming
  68. a tiny bitmap in hardware.
  69.  
  70. Even more for your code to consider.
  71.  
  72. >what ? I say a game programer is more likely to use OS if it's excelent
  73. >in speed end got a useful interface.
  74.  
  75. I say that a c00l c0d3r (and that's most of all game programmers we
  76. have) does never use the OS. Even your proposals for low-level access
  77. to graphics hardware are just a way to avoid the OS as much as possible.
  78.  
  79. >Also nobody is forced to use the OS. 
  80.  
  81. We know that.
  82.  
  83. -- 
  84.                                 Michael van Elst
  85.  
  86. Internet: mlelstv@serpens.rhein.de
  87.                                 "A potential Snark may lurk in every tree."
  88.